Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: move to scikit-build-core #126

Merged
merged 5 commits into from
May 25, 2024

Conversation

henryiii
Copy link
Contributor

@henryiii henryiii commented Mar 20, 2024

Close #104.

I didn't include these files in the existing wheel:

./swig-4.2.1.data/data/LICENSE-SWIG
./swig-4.2.1.data/data/CMakeLists.txt
./swig-4.2.1.data/data/LICENSE-UNIVERSITIES
./swig-4.2.1.data/data/README.md
./swig-4.2.1.data/data/LICENSE-GPL

as the licenses are already in the correct place in the diet-info folder, people don't need the CMakeLists.txt or README.md, and these get installed to the root of the environment! For a virtualenv, that's bad:

$ uv venv
$ uv pip install swig
$ ls .venv
CACHEDIR.TAG          LICENSE-GPL           LICENSE-UNIVERSITIES  bin/                  pyvenv.cfg
CMakeLists.txt        LICENSE-SWIG          README.md             lib

And for a global install, that's horrible:

$ docker run --rm -it python:3.12 bash
# pip install swig
# ls /usr/local
CMakeLists.txt	LICENSE-GPL  LICENSE-SWIG  LICENSE-UNIVERSITIES  README.md  bin  etc  games  include  lib  man	sbin  share  src

The second commit uses a single macOS universal wheel with ARM and Intel tags also included. I could remove that if you'd prefer multiple smaller wheels. As it is, pip will never download the universal wheel, since it will get the most specific one.

@henryiii henryiii marked this pull request as ready for review March 20, 2024 08:24
Signed-off-by: Henry Schreiner <henryschreineriii@gmail.com>
Signed-off-by: Henry Schreiner <henryschreineriii@gmail.com>
@henryiii henryiii force-pushed the henryiii/feat/skbuild branch from 92487d9 to 80f4c10 Compare March 20, 2024 08:38
@nightlark
Copy link
Owner

Thank you!! 😃

@henryiii
Copy link
Contributor Author

Do you really want to support manylinux1? It's been abandoned by most projects & is years past EoL. The oldest cmake we still ship is 2010 (and highly recommend 2014). I can require binaries and see what the newest cmake to support manylinux1 was.

Signed-off-by: Henry Schreiner <henryschreineriii@gmail.com>
@henryiii
Copy link
Contributor Author

Hopefully I remembered how to do that. :)

@henryiii
Copy link
Contributor Author

henryiii commented Mar 22, 2024

FYI, the last cmake we shipped for manylinux1 was 3.22.6.

$ PIP_ONLY_BINARY=:all: docker run -e PIP_ONLY_BINARY --rm quay.io/pypa/manylinux1_x86_64 pipx run cmake --version
...
cmake version 3.22.6
...

@nightlark
Copy link
Owner

For supporting manylinux1 it's mostly been if the builds work with minimal hassle, might as well keep building them for users that haven't been able to update their Python/OS yet -- not sure if I'm reading it right, but from https://mayeut.github.io/manylinux-timeline/ it looks like there's maybe 3-5% of users with Python <=3.7 that only support manylinux1.

pyproject.toml Outdated Show resolved Hide resolved
@nightlark nightlark merged commit bbcf58e into nightlark:main May 25, 2024
15 checks passed
@nightlark nightlark added the enhancement New feature or request label May 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Migrate from scikit-build to scikit-build-core
2 participants